New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate passing parameters to Statement::execute*() #5556
Deprecate passing parameters to Statement::execute*() #5556
Conversation
0c9f45e
to
2c12361
Compare
Isn't this exactly the oposite of simillar newly introdue php function to mysqli - php/php-src#8660? |
No. The newly introduced |
In Symfony, I would like to confirm the change with you, please because a deprecation appears in my case since Symfony 6.3 was released. Deprecation : Tell my if I'm wrong, we can't do this right now : // src/Repository/ProductRepository.php
// ...
class ProductRepository extends ServiceEntityRepository
{
public function findProductByPriceQuantityAndCategory(int $price, float $quantity, string $category): array
{
$conn = $this->getEntityManager()->getConnection();
$sql = '
SELECT * FROM product p
WHERE p.price > :price
AND quantity >= :quantity
AND category = :category
ORDER BY p.price ASC
';
$stmt = $conn->prepare($sql);
$resultSet = $stmt->executeQuery([
'price' => $price,
'quantity' => $quantity,
'category ' => $category,
]);
// returns an array of arrays (i.e. a raw data set)
return $resultSet->fetchAllAssociative();
}
} Do we have to use [
'price' => $price,
'quantity' => $quantity,
'category ' => $category,
] (I haven't found anything about this particular case on DBAL/Documentation/Data Retrieval And Manipulation and DBAL/UPGRADE). |
There is an |
Tanks 🙂@derrabus |
…eQuery` (vinceAmstoutz) This PR was submitted for the 6.3 branch but it was squashed and merged into the 6.2 branch instead. Discussion ---------- Fix `doctrine/dbal` deprecation using `Statement::executeQuery` Deprecation warning when `doctrine/dbal >= 3.4.*`. In Symfony docs,executeQuery() is mentionned here : [Querying with SQL](https://symfony.com/doc/current/doctrine.html#querying-with-sql). But since `3.4.*` passing parameters to `Statement::execute*()` functions is deprecated by `doctrine/dbal` with this warning: `User Deprecated: Passing $params to Statement::executeQuery() is deprecated. Bind parameters using Statement::bindParam() or Statement::bindValue() instead. (Statement.php:212 called by User.php:40, doctrine/dbal#5556, package doctrine/dbal)`. I've already ask in the [DBAL PR concerned](doctrine/dbal#5556 (comment)) how to use `executeQuery` from now on. ![image](https://github.com/symfony/symfony-docs/assets/46444652/e0b6938b-4f67-474a-a8f5-5f565b04e5b4) [(in the same PR)](doctrine/dbal#5556 (comment)) So, after having tested it in a prod project, I propose an update of the doc in this sense. Thanks again `@derrabus` 🙏 Commits ------- 5c8154b Fix `doctrine/dbal` deprecation using `Statement::executeQuery`
IMHO this decision is a bad decision that doesn't provide any advantage to the community. (of course we could use I hope an alternative will be reintroduced. |
You can also call |
What if there is a variable number of values? ($values - array with variable number of values). |
$sql = 'SELECT COUNT(*) AS count FROM table t <...> AND t.id IN (:ids)';
return $this->connection->executeQuery($sql, ['ids' => $values], ['ids' => ArrayParameterType::INTEGER]); |
Being able to bind parameters to the statements via
execute($params)
is a PDO legacy and has the following downsides:Statement::bindParam()
and::bindValue()
methods which accept 1-based numeric parameter positions,execute($params)
expects 0-based indexes for positional parameters. This results in the inconsistency in logging statement parameters as reported in Inconsistent parameter indexes passed to the logging middleware #5525.$params
in a given call toStatement::execute()
should have integer or string keys since it depends on how parameters were declared in the SQL used to prepare the statement.$params
toexecute()
of a statement that already has parameters bound viabindParam()
orbindValue()
is undefined. Do parameters get merged or the previously bound parameters get ignored?$params
toexecute()
is undefined. Do the corresponding values remain bound to the statement or they are used only for this call? For reference, they remain bound to the wrapper statement but the driver-level behavior is undefined and is defined by the DBAL-level or the underlying driver.The even bigger problem is that the wrapper level uses the same API for binding positional and named parameters that results in ugly and incorrect types like
list<...>|array<string,...>
. Whether the statement parameters are positional or named is decided at runtime. Deprecating this feature is the first step toward introducing separate APIs for positional and named parameters.Affected API consumers:
Statement::bindValue()
for binding parameters to the statement.executeQuery($sql, $params, $types)
.